home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Columbia Kermit
/
kermit.zip
/
newsgroups
/
misc.19970104-19970326
/
000178_news@columbia.edu _Mon Feb 3 08:00:59 1997.msg
< prev
next >
Wrap
Internet Message Format
|
2020-01-01
|
3KB
Return-Path: <news@columbia.edu>
Received: from newsmaster.cc.columbia.edu (newsmaster.cc.columbia.edu [128.59.35.30])
by watsun.cc.columbia.edu (8.8.5/8.8.5) with ESMTP id IAA11053
for <kermit.misc@watsun.cc.columbia.edu>; Mon, 3 Feb 1997 08:00:58 -0500 (EST)
Received: (from news@localhost)
by newsmaster.cc.columbia.edu (8.8.5/8.8.5) id IAA18124
for kermit.misc@watsun; Mon, 3 Feb 1997 08:00:57 -0500 (EST)
Path: news.columbia.edu!psinntp!howland.erols.net!cs.utexas.edu!news.cs.utah.edu!cc.usu.edu!jrd
From: jrd@cc.usu.edu (Joe Doupnik)
Newsgroups: comp.protocols.kermit.misc
Subject: Re: K95 xfer works when FTP doesn't?????
Message-ID: <1997Feb2.175835.93143@cc.usu.edu>
Date: 2 Feb 97 17:58:35 MDT
References: <32f2266f.55500445@199.1.22.49> <5cukr2$14t$1@apakabar.cc.columbia.edu>
Organization: Utah State University
Lines: 44
Xref: news.columbia.edu comp.protocols.kermit.misc:6525
In article <5cukr2$14t$1@apakabar.cc.columbia.edu>, jaltman@watsun.cc.columbia.edu (Jeffrey Altman) writes:
> In article <32f2266f.55500445@199.1.22.49>,
> Vincent Fatica <vefatica@syr.edu> wrote:
> : Is there some profound difference between sending files via FTP vs.
> : via Kermit/TCPIP?
> :
> : Here's what's happening: On a PPP connection with a provider called
> : servtech, whenever I try to upload via FTP from home to a site outside
> :
> : servtech.com, it bogs right down to almost nothing (<100 cps). But I
> : can Kermit (via TCP/IP) the same file to the same host, on the same
> : connection, at the expected 3000 cps. I don't get it. Kermit is just
> : sending out TCPIP packets just like (?) FTP, isn't it? What might
> : account for FTP being horribly slow when Kermit is working normally?
> :
> : Also, I have been playing with a HTML server on my NT machine. It
> : behaves like FTP when trying to send something out onto the internet
> : ... god-awful slow.
>
> This is only a guess, but it sounds like someone's TCP/IP implementation
> of TCP flow control is bad. FTP/HTTP send files by opening a socket and
> sending data without any data being sent back in response. Therefore,
> when the TCP window fills and data gets stopped, the restart signal is
> not getting through or not getting sent.
>
> Kermit transfers continuously send data in both directions. Therefore,
> the available window size is always being piggy backed on top of real
> data packets.
>
> Sounds like someone is trashing TCP packets with 0 data.
--------
Um, er, not really.
FTP and HTPP and Telnet and a big bunch of other well know applications
all use TCP/IP for transport. TCP/IP is TCP over IP, with its own congestion
control techniques. There is no such thing as send and send and expect no
response. On average every second TCP data segment is ACK'd.
Vincent didn't mention details about whose TCP/IP stack etc so
speculating is definitely limited here. Since it's not really our task to
decipher the FTP clients of other vendors I suggest you contact their Tech
Support group, and your ISP, and ask for words of wisdom. Before doing so
please triple check the modem setup to avoid XON/XOFF flow control (that's
fatal for TCP/IP) and instead use RTS/CTS hardware flow control.
Joe D.